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Abstract 

Different sectors are being revolutionized by distributed ledger technology. 
According to the 2022 market valuation, Hyperledger is now the second-largest 
blockchain platform for smart contracts. The creation of numerous apps may 
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y be sped up and simplified with smart contracts, but there are certain draw- 
Smart Contract; ; Pie ; : 
SLA: backs as well. For instance, vulnerability contracts are created intentionally 
Hyperledger Fabric; to weaken candor, smart contracts are employed to conduct fraudulent activ- 
Blockchain; ities, and there are many redundant contracts that squander the efficiency of 
LSTM the system for no real reason. To solve these problems, we provide in this 


research Service Level Agreement(SLA) for Hyperledger smart contracts. We 
created Hyperledger smart contracts and focused on how smart contracts and 
consumers used data. By manually analyzing the transactions, we were able 
to extract four behavioral characteristics that may be used to differentiate 
between various contract types. Then, a smart contract is built using these 
to include 14 fundamental functionalities. We provide a data splitting algo- 
rithm for splitting the gathered smart contracts in order to create the experi- 
mental dataset. Then, we train and test our dataset using an LSTM network. 
The comprehensive experimental findings demonstrate that our method can dis- 
criminate between various contract types and may be used to identify malicious 
contracts and detect anomalies with acceptable precision, recall, and F 1-score. 


1. Introduction inal digital currency distribution transaction to 
include banking, medical, the Internet of Things, 
software engineering, and other industries (X. Li 
et al.). The first successful implementation of 
blockchain technology was Bitcoin (Nakamoto). In 
2015 (Desjardins) and 2016 (X. Li et al.), Bit- 
coin was hailed as the masterpiece in digital market 
and commodities, respectively. One of the systems 
for permissioned blockchains is Hyperledger Fab- 


The transactions in digital currencies are 
recorded using the decentralized, distributed tech- 
nology known as blockchain (X. Li et al.). Decen- 
tralization, permanence, anonymity, and auditabil- 
ity are just a few of the advantages this gives the 
blockchain (Zheng et al.). As a result, blockchain 
technology has advanced quickly in recent years, 
and its use cases have expanded beyond the orig- 
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ric (Androulaki, Barger, and Bortnikov). The Linux 
Foundation created it, and it is open-sourced. Every 
component serves a unique purpose according to its 
job. The four primary steps of the transaction flow 
are endorsement, ordering, validation, and commit- 
ting. Prior to a network’s start, each component has 
to be tailored and defined according to the network’s 
specifications. To launch their bespoke fabric net- 
work, designers need to deal with a multitude of fac- 
tors surrounding all components. The fabric is made 
up of a number of different parts, including peer 
nodes, clients, membership, an ordering service, and 
Chaincode. Most blockchain networks are built for 
the purpose of transferring and storing money, and 
in most cases, this involves producing a currency” 
that is used on the network. The word ”assets”’ is 
used generally in relation to Hyperledger Fabric (D 
et al.). Cash, real estate, a car, or even an insurance 
policy are all examples of assets. Its main differ- 
ence from most other blockchain networks is that it 
will be used by workers of one or more organiza- 
tions rather than by individuals. It provides a variety 
of possibilities rather than a single standard of work 
for the blockchain network. It may be simpler to 
construct a network in this fashion so that it may be 
implemented within the business model of the firm 
in question. 


2. Background 


By employing a model, the model and the 
Calipers benchmark tool, overall performance and 
delay of HLF version | were investigated in (Baliga 
et al.). The study investigated the effects of several 
Chaincodes variables and various transactions on 
transactions performance and latency under micro 
workloads. By incorporating different numbers of 
Chaincodes, routes, and neighbors, the authors eval- 
uated the efficacy of Hyperledger Fabric character- 
istics. The evaluation findings demonstrated how 
sensitive HLF v1.0 performance is to the Ordered 
option. Also, the outcomes demonstrated that the 
HLF v1.0 Compiler was unable to manage a trans- 
action in concurrently using numerous virtual CPUs 
(vCPUs). That can be viewed as a speed constraint 
for the system. 


Through incorporating additional applications to 
the platform and nodes scales, Nasir et al. in (Nasir 
et al.) conducted an experimental efficiency study of 
two distinct flavors of HLF (v0.6 and v1.0) to exam- 
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ine the completion time, performance, delay, and 
adaptability. The findings demonstrated that across 
all important performance indicators, HLF v1.0 usu- 
ally beat HLF v0.6. 


In (Kuzlu et al.), the authors assessed the HLF 
v1.4 platform’s performance in terms of ’m getting, 
delay, and scaling with a range of network work- 
loads, including diverse transaction volumes, types, 
and rates. 


The research explained in (Wang) with devel- 
oped different malicious behaviour patterns exam- 
ined the effect of malicious conduct on the transac- 
tional latency and throughput aspects of HLF perfor- 
mance. The results revealed a considerable decrease 
in systems efficiency because of assault delay as 
well as the failure of certain duplicates. 


A revolutionary architecture was put forth in 
Paper (W. Li et al.) to improve the durability of pub- 
lic blockchains. The new design solves the scalabil- 
ity problem of individual Byzantine-fault-tolerant- 
based (BFT) systems like HLF v0.6 and offers satel- 
lites chains to establish a collection of networks. 
Secure resource transfer across network is possible 
with suggested design. 


A information middle and high the Ethereum 
Blockchain was created in (Takahashi, Kanai, and 
Nakazato). A range of process and function, includ- 
ing photos and 3d models, were used to test the 
study’s validity in order to show how well the block 
chain technology performs overall when used for 
exchanging sensor information. 


2.1. Hyperledger Fabric 


Hyper ledger fabric is a blockchain platform with 
permissions wherein users may see and trust one 
another. However, it might be set up according to 
the model of governance developed in order to fos- 
ter confidence among the users. The orchestration 
and deployment of distributed ledgers inside coali- 
tions depends on the participation of the collaborat- 
ing entities. The blockchain is hosted by nodes (or 
peers), who also execute smart contracts and cooper- 
ate to keep apprised of the current state of the record. 
The common Chaincode can be implemented by all 
entities or developed privately thanks to the HLF’s 
channel idea. Chain codes may be sent to a set of 
nodes in a private manner, rendering them inaccessi- 
ble to other nodes. Only those who subscribe to this 
very same network have access to the information 
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and Chaincode. To recognise and verify the nodes, 
the HLF system must use encrypted resources cre- 
ated by itself. Consequently, this method may be 
used to authorise certain existing customers. The 
approved transactions are ordered by the network 
according to each channel The approved transac- 
tions are ordered by the network according to each 
channel. Figure 1 displays the comprehensive HLF 
system design. 


2.2. Transaction Flow in Hyperledger Fabric 


The transactional method used by HLF is execute- 
order-validate-and-commit (EOVC). The transac- 
tional process of the HFL private ledger is depicted 
in Figure 2. The stages involved are verification, 
sorting, and approval. Chaincode spellcasters are 
Docker (Shahbazi and Byun) container-based trans- 
actions. Therefore, separating them from other 
active chaincodes on the same host as well as the 
HLF codes would indeed be beneficial. The network 
nodes maintain a record of transactions as part of the 
private ledger technology known as HLF. The struc- 
ture of the data and the status of the data are the 
two components of the blockchain. The state data 
describes the nodes’ actual situation at any given 
time, whereas the transaction log records all activ- 
ities that have been invoked. By running the chain- 
code, several actions might be performed on the cur- 
rent data status. Transactions are created during pro- 
cessing and added to the log file. The state’s statis- 
tics may also alter as a result. The LevelDB, a com- 
pact library for creating a key-value data store inte- 
grated into the HLF node implementation, is used 
to generate the ledger of transactions. The combi- 
nations of session keys make up the status meta- 
data. At the node level, the status database is hot- 
swappable. A straightforward query for key-value 
pairs is supported by LevelDB. The CouchDB and 
NoSQL databases that enable the execution of com- 
plicated requests may nevertheless substitute for it. 
Prior to actually initiating the HLF transaction pro- 
cessing, it is necessary to reveal the credentials of 
involved stakeholders, associated MSPs, and neigh- 
bors. Upon that Orderer system’s activation, the net- 
work must be started with the appropriate organiza- 
tion’s MSPs and nodes joining the channel and ini- 
tialising the blockchain. Furthermore, the link must 
have the necessary chaincodes implemented. 
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2.2.1. Phase 1 — Endorsement Phase: 


According to the endorsement rule encoded in the 
Chaincode, client apps employing the HLF-SDK 
(Hyper Ledger Fabric Software Development Kit) 
generate a demand suggestion as well as propose the 
transaction to endorsing peers. The request is signed 
cryptographically by the client and sent over simi- 
lar channels as the blockchain network. The sug- 
gested transactions are carried out by the endors- 
ing peers, who also get the predictable output. An 
endorsement rule must be specified while imple- 
menting the Chaincode to determine whose peers 
(organisations) have had the authority to approve 
a transaction in the shared smart ledger so that 
it can be accepted as legitimate and added to 
the blockchain. To make sure that agreement is 
reached among all the peers in the process, the HLF 
takes a number of actions, including establishing 
endorsement guidelines for ordering services. The 
sequence of transactions is execute-order-validate- 
commit (EOVC).Client interactions were first car- 
ried out in sandbox environments to ascertain their 
read-write sets, or the collection of keys that the 
payment transactions will read from and write to. 
The transactions are then ordered by an ordering 
service before being verified and committed to the 
blockchain. This procedure is carried out by nodes 
with designated duties. The read-write sets, reply 
values, and crypto-graphic data that were generated 
as a consequence of blockchain code processing are 
all included in the endorsement reply. The endors- 
ing peer delivers a proposed answer to the client 
after signing the transactional response with their 
identity using the Chaincode ESCC (Endorsement 
System Chain Code) system. At this moment, noth- 
ing has altered with the ledger. Client application 
programmes gather recommendations from a vari- 
ety of endorsing peers and provide them to an order- 
ing phase in accordance with the endorsement rule 
established by Chaincodes. 


2.2.2. Phase 2 - Ordering Phase: 


The ordering service audits each transaction in 
chaincode. They are arranged by network. The 
transactions that were ordered must then be deliv- 
ered by the ordering service. A block, which is 
a transaction transmitted to every peer within the 
same order by the ordering service, is required by 
every peer. Any of the established ordering meth- 
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FIGURE 2. Fabric transaction flow. 


ods, including Kafka, Solo, or Raft, is used by the 
ordering service (Shahbazi and Byun). One order- 
ing service node makes up the Solo ordering algo- 
rithm. It is employed for system design that runs on 
a node. The Kafka algorithm is more fully imple- 
mented. The Kafka group is created in order to pro- 
duce and ingest transactions. As a result, it offers 
crash fault tolerance (CFT) and therefore is advised 
for a continuous growing list of records in a produc- 
tion setting. The Raft is comparable to the Kafka 
due to its own commander structure. Its CFT sta- 
tus is a benefit. The raft’s configuration is somewhat 
simple. In order to see if client nodes can transmit or 
accept blocks on a specific channel, the ordering ser- 
vice must run access control permission checks on 
the client nodes. SOLO use is permitted by Hyper- 
ledger Fabric version 1.4. It is a message sent from 
the middle of the gateway, which is simply config- 
ured with one node. In a configuration that is bet- 
ter suited for a development stage, no cluster func- 
tionality is provided. Nevertheless, the network now 
has a single failure point. Development teams don’t 
think about using it in operations. 


Kafka would be used in the finished versions of 


HLF. High bandwidth and scalability are features of 
this communication program. It is possible to accept 
fault tolerance when using a cluster. Multiple com- 
munication channels could be tested with different 
setups because Kafka and SOLO both allow them. 
A user receives the Orderer to advertise the endorsed 
transactions to the different peers. The customer 
receives the responses, which are the endorsements 
from the endorsing peers. The client is prepared 
to distribute it to multiple network peers. This 
step is accomplished by invoking the orderer for 
the broadcast services. The anchoring peers within 
that organisation distribute the blocks to the differ- 
ent additional peers after obtaining the blocks con- 
taining the transaction. As a result, the person who 
ordered provides the communication layer of the 
HLF channel. It is in charge of maintaining the time- 
line and plays an important role in the consensus 
protocol. 


2.2.3. Phase 3 - Validation Phase: 


The transactions must be verified after the blocks 
has been distributed to all network nodes using the 
ordering phase provider or chatter protocol. Incor- 
rect transactions are found and rejected through- 
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out the validation phase. Only legitimate transac- 
tions thus are committed as well as maintained in 
the fabric ledger as well as the world level state. 
The validation services comprise of two sequential 
steps: read and write discrepancy checking, often 
known as Multi-version Concurrency Access Con- 
trols (MVCAC), and analysis of endorsement phase 
using the Validation System Chain Code (VSCC). 


2.3. Key Indicators and Tuning Factors 


The goal of this work is to examine the efficiency of 
the modular HLF in a distributed architecture with 
varied levels of nodes and circumstances in order 
to determine whether certain factors impact system 
performance. The research is confined to a deep 
examination of a few characteristics, while other 
elements are discussed in broad strokes in order to 
comprehend and characterise the interrelationships 
of nodes. As a result, the central emphasis is on 
examining holistic performance from the vantage 
point of peers. Concurrently, the Orderer and Gossip 
effects on the investigation were removed because 
they were fixed. Figure 3 depicts the overarching 
test system and its subsystems. A solitary HLF sys- 
tem of one user executing assessment utilities and 
one anchorage is included in the design. 


2.3.1. Performances Parameters: 


A report with accurate performance measurements 
that are relevant to multiple DLT platforms was cre- 
ated by the Hyper-ledger fabric Performance as well 
as Scalability Workgroup. It was applied inside the 
experiments and analyses that were described. 


2.3.2. Transaction Efficiency: 


Smart contracts are deployed, executed, and invoked 
at varying rates in various public blockchain system. 
Hence, it is necessary to keep an eye on transaction 
efficiency. It is calculated as the rate at which the 
HLF network commits legitimate transactions over a 
predetermined time frame. The assessment at a sin- 
gle peer is taken into account for the Hyper Ledger 
Fabric network with one channel. Furthermore, the 
trials were expanded to include numerous peers in 
the published framework and analyses (up to 500). 


2.3.3. Latency Transaction: 


It takes a while for the computer to verify the trans- 
actions after it has been transmitted to a connection. 
The length of time between the period a transaction 
which performed and the period is confirmed, com- 
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mitted, and the outcome is made accessible through- 
out the network is known as the transaction latency. 
Each transaction counts toward this metric. But in 
the majority of situations, the experiment offers dif- 
ferent statistics on total transactions, including low, 
high, medium and standard deviations. The transac- 
tions verification at a one peer and several peers hav- 
ing various levels of load were examined in the study 
that was published. Three factors make up the esti- 
mated end-to-end transmission delay: the commit, 
ordering, validation and endorsement phase (Jamil 
et al.). 


2.3.4. Scalability: 


The capacity of both the deployed HLF network to 
assist growing the member base is calculated in this 
study. The scale of the network corresponds to the 
number of verifying peers taking part in SUT con- 
sensus. The limited network is displayed to reflect 
the overall number of nodes that are currently using 
the HLF public blockchain network. 


2.3.5. Size of the Block: 


The three parameters that make up the size of the 
block—the maximum transaction count per second 
is calculated, the absolute maximum byte values, 
and the recommended maximum bytes—present the 
number of transactions per block seconds. A block 
of transactions is batch processed. The assessment is 
further expanded in the study to incorporate batches 
of numerous blocks value (1 blocks, 10 blocks, 50 
blocks and 100 blocks). Additionally, it investigates 
how various batch sizes affect HLF systems. 


3. Environmental Setup 


HLPF’s efficiency and scalability were assessed by 
implementing several sets of parameters such as 
transaction sending time, size of the block, size 
of the network, and NetFlow delivery. The study 
was performed to evaluate has taken into account 
a number of measures, including network speed, 
average sale latency, and available resources. By 
expanding the connection, scalability was evalu- 
ated based on changes in bandwidth and transaction 
delay. The test findings highlight efficiency bottle- 
necks, explain the effect of a particular parameter 
on the HLF public blockchain network, and demon- 
strate how changes may be made to improve effi- 
ciency. 

The detailed experimental design used in all of the 
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experiments is illustrated in Figure 4. In each case, a 
public blockchain HLF connection was established, 
including one organisation and numerous peers. A 
through-for was used to construct the ordering sys- 
tem, which was executed on a different node. To 
make the prescribed responsibilities easier, a line of 
code was put into use on the network. 


A permissionless HLF blockchain network was 
set up in a managed distributed manner. Many Ama- 
zon Web services (AWS) EC2 instances were set up 
as such an underground node-based network in order 
to get accurate outcomes. Table 1 summarizes the 
parameters of SUT. Running every instance on its 
own Virtual Machine (VM). To lessen the impact of 
connection delays throughout the studies, all VMs 
were connected to a single subnet. The identical 
experiment was carried out multiple times with vari- 
ous peer and node values. KV stands for a Key Value 
that will be communicated to the public blockchain 
network as a result of a transactions. 


IoT gateways in AWS were designed after EC2 
instances. The IoT system has adopted different 
messaging exchanges as chain transactions. This 
test benchmark system was performed on an AWS 
EC2 instances with 2vCPUs, 3.0 GHz Xeon Plat- 
inum processors, and 4GB RAM. The AWS EC2 
machine was running Hyperledger Fabric version 
v1.4 together with peers, CA, OS, and Ubuntu 18.04 
LTS. The effectiveness of the equipment choice (1.e., 
CPU and RAM) on the bandwidth, delay, and scal- 
ability of the developed public blockchain network 
was examined using that testing environment. VM 
runs Docker on multiple computer systems to issue 


transactions. HLF version 1.4 is a permissioned 
blockchain network application. To perform mul- 
tiple chains of code, the VM hosts the HLC (Hyper- 
ledger Caliper). The various network peers (from 
1 peer to 500 peers) in a scalable environment It 
deploys Docker to connect Docker swarms to man- 
age the speed of the container. Multiple nodes uses 
Ubuntu 18.04 LTS OS. 


The strength of a Proof of Work (PoW) agree- 
ment is evident. because of it is thought to be safest 
solution for cryptocurrency application because of 
its pseudo anonymous character. The players in 
the chain already are familiar with one another in 
business environments like Distributed systems and 
telecommunications environments, thus it seemed 
superfluous in those settings. Consequently, private 
blockchain blockchains were made for use in busi- 
nesses. Platforms that employ consensus mecha- 
nism that are simpler & utilise fewer resources, such 
Raft (Ongaro and Ousterhout), which was used in 
this work. 


To reduce this effectiveness, straightforward 
transactions must be used. Every transaction pro- 
duces a number that is added to a value accord- 
ing to the system time specified in the blockchain. 
These variables each produce a key-value pair that 
also contains a constant rate. Writing the ledger 
with transactions requires the blockchain. Peers are 
allowed to make transactions, and they execute in a 
secure, isolated Docker container. Every action is 
indeed a write operation that alters the world. The 
endorsers then independently execute the chaincode, 
create a transactional report based on the execution 
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FIGURE 4. Experimental setup for Performance Evolution 


TABLE 1. System under test parameters and values 


Parameters Values 

Size of Blocks 30 tps 

Benchmark out time 1000 ms 

Rate of Tx Sending 1-500tps 

Number of Blockchain 1,10,50,100 tps 

Channels 1 channel 

DB State level Level DB 

Transactions 1 KV of 20bytes size 

Peers 100v CPU, 3.3 GHZ size, 10 GiB, Moderate network size 


outcomes, and verify the reply. The verified transac- 
tion request answer is the last thing that the applica- 
tion receives. 


4. Summary 


To assess the performance and scaling of the Hyper- 
ledger Fabric framework in a virtualized environ- 
ment, many instances with diverse hosts within the 
network (ranging from | to 500 hosts) have been 
tested. The studies were done in a single-host con- 
text with an identical setup. In Hyperledger Fabric 
version 1, the HLF implemented the concept of dif- 
ferent firms. This version | was implemented on 
a multi-host system of virtualized implementations, 
and the system was measured. Number of oper- 
ations per unit time, delay, node density, resource 
utilization, and acceptance policies are examples of 
key metrics. The outcomes were compared to a soli- 
tary host implementation system. It performed bet- 
ter on the majority of the measures. Unfortunately, 
that approach was not relevant in practice. Simulta- 
neously, the efficiency of multiple-host designs may 
be improved by deploying numerous organisation 


concepts, each with its own systemiser. 

The experiments have numerous parameters, such 
as the peers, size of blocks, and frequency at which 
transactions are sent, are listed in Table 2. Each test 
begins with transactions being sent at speeds rang- 
ing from 1 to 500 tps. 


4.1. Analysis of Single host and Multiple host 
Transaction 


In a single-host configuration, Figure 5 shows the 
average efficiency of various blocks over varied 
transaction transmission rates. The average delay 
for the same transaction sending rates is shown in 
Figure 6. 

In a Multiple-host configuration, Figure 7 shows 
the average efficiency of various blocks over var- 
ied transaction transmission rates and the average 
efficiency for the same transaction sending rates is 
shown in Figure 8. 

The resulting performance and average delay met- 
rics are shown in Figures 9 and 10. The findings 
indicate that both situations exhibit a nearly identi- 
cal delay pattern up to the highest peak. The trans- 
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TABLE 2. Parameter used for single and multiple transactions of network nodes 


Parameters Values 
Peers 1, 5, 10, 20, 30, 40, ..., 90, 100 
Size of the Block 1, 10, 50 


Rate of Transactions send 


FIGURE 5. Single Host: Transactions sending 
rate vs Efficiency 


Peers 


) angst 


FIGURE 6. Single Host: Transactions sending 
rate vs latency 


FIGURE 7. Multiple host: Transactions sending 
rate vs Efficiency 


actions delay with a single server host endorsement 
indicates superior efficiency after the peak point. 
Despite having varied major position for different 
configurations, the bandwidth effect increases in 
each scenario. 

Figures 11 and 12 demonstrate that improvement 
is possible with an improvement in block size. The 


1,5, 10, 20, 30, 40,..., 90, 100, 200,... 400, 500 


FIGURE 8. Transactions sending rate vs latency 
for multiple host arrangement. 


eR 


FIGURE 9. Transactions sending rate vs effi- 
ciency for different endorsement phase 


+007 


Transaction Sending Rate (TPS) 


FIGURE 10. Transactions sending rate vs 
latency for different endorsement phase. 


block refers to the number of transactions that can 
be contained in a block before it is released to the 
public blockchain network. The Arrange a meeting 
Batch Size can have a big impact on how fast the 
system runs. The outcomes demonstrate that what a 
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small feature size blocks decreases performance. 


Peers 


Efficiency 


Transaction Sending Rate (TPS) 


FIGURE 11. Effect of block sizes on system with 
efficiency. 


FIGURE 12. Effects of block sizes on transac- 
tions with latency 


The efficiency and average delays for transactions 
with various send rates up to 2500 tps are shown in 
Figures 13 and 14. 


° 


Efficienc 


5 i} 
Transaction Sending Rate (TPS) 


FIGURE 13. Effects of size of the network on the 
system with efficiency. 


The average peer CPU use is shown in Figure 
15. Figure 16 illustrates the average disc write uti- 
lization and shows the linear increases with small 
batches as well as the amount of peers. Similar 
trends of aggregate memory usage by networking 
neighbours are shown in Figure 17. 

Figures 18 & 19 show the Network input and 
ouput Traffic of the peers respectively. 
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Transaction Sending Rate (1PS) 


FIGURE 14. Effects of size of the network on 
transaction with latency 


FIGURE 15. Average CPU usage of Peers 
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Average Disc Write (MB) 
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FIGURE 16. Average writes disk usage of peers 


Average (MB) 
x+007 
» r® 


Memory 


Rate (TPS) 


FIGURE 17. 
usage of peers 


Average memory consumption 
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FIGURE 18. 
usage of peers 


Average Network traffic input 


saction Rate (TPS) 


FIGURE 19. Average Network traffic output 
usage of peers 


4.2. Evaluation Metrics 


To assess the effectiveness of their systems, we 
employ the Precision (P), Recall (R), and Fl 
score (Fl) metrics. The term ’true positive” (TP) 
describes how many smart contract forecasts were 
accurate. False positive (FP) refers to the quantity 
of incorrectly classifying this kind as an alterna- 
tive type. Also known as a false negative, this type 
has been mistakenly classified as a variety of differ- 
ent types. The better it is to discriminate between 
the various forms of smart contracts, the greater the 
value of precision, recall, and F1 score. 

We have two ways of gathering contract infor- 
mation. One is to synchronise all previously pro- 
cessed transaction information using the client. The 
alternative is to extract a smart contract’s transac- 
tions and store them in JSON format using the APIs 
offered (Ongaro and Ousterhout). We also consult 
the DApp publication website (Christidis and Devet- 
sikiotis) in accordance with the various uses of smart 
contracts before classifying the three most prevalent 
types. 

hows the total number of smart contracts in stock 
market, media and sports. Tables 4-6 showed how 
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TABLE 3. Number of smart contracts in each 
different type 


Stock Market Media Sports 
2930 


Types 
Count 782 338 


one type of contract differed from other types, illus- 
trating how the characteristics we glean from smart 
contract transactions might describe the behavioural 
patterns of many types of contracts. With respect 
to these other kinds of contracts, Table 4-6 Preci- 
sion of sports contracts ranges from 0.902 to 0.955, 
which indicates that more than 92% of sports of 
smart contracts can be identified from other kinds by 
the features. The Recall varied from 0.919 to 0.977, 
indicating that the more than 92% of contracts with 
sports characteristics were accurately classified as 
such. The categorization performance of our models 
is good, as evidenced by the Fl-score, which ranges 
from 0.916 to 0.982. Our experiment makes use of 
all 14 of these attributes, and the findings indicate 
that they can accurately capture the traits of various 
contract kinds. However, we also discovered that the 
reliability of the experimental data will be impacted 
if some smart contracts also have little transactions. 


TABLE 4. Result of Stock Market applications 
with different smart contracts 


Type Precision Recall F1-Score 

Media 0.932(+/- 0.924(+/- 0.939(+/- 
0.006) 0.009) 0.006) 

Sports 0.932(+/- 0.826(+/- 0.876(+/- 
0.019) 0.025) 0.019) 


TABLE 5. Result of Media applications with dif- 
ferent smart contracts 


Type Precision Recall F1-Score 

Media 0.932(+/- 0.924(+/- 0.939(+/- 
0.006) 0.009) 0.006) 

Sports 0.932(+/- 0.826(+/- 0.876(+/- 
0.019) 0.025) 0.019) 


Table 7 shows the difference between each one 
type of contracts which has some differences which 
varies +/- values is shown for stock market, sports 
and F1- score. 

Focus on F1 score is between 0.701 to 0.835 and 
overall results are shown using LSTM network 
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TABLE 6. Result of Sports applications with dif- 
ferent smart contracts 


Type Precision Recall F1-Score 
Stock 0.912(4+/- 0.919(4+/- 0.91 6(4/- 
Market —_(0.013) 0.015) 0.013) 
Media 0.885(+/- 0.837(4+/- —_-0.860(+/- 
0.025) 0.020) 0.015) 


TABLE 7. Results of different types of each sin- 
gle smart contracts. 


Type Precision _ Recall F1-Score 
Stock 0.940(4+/-  0.858(4/- —-0.897(+4/- 
Market 0.013) 0.016) 0.014) 
Sports 0.837(+/- 0.848(4/- —-0.876(+4/- 
0.013) 0.015) 0.014) 
Media 0.888(4+/-  0.706(+/- ——- 0.78 6(+4/- 
0.020) 0.026) 0.020) 


TABLE 8. Results of different types of smart con- 
tracts with LSTM Network 


Type Precision Recall F1-Score 
Stock 0.805(+/- —0.783(4/- ——-0.793(4/- 
Market 0.052) 0.036) 0.039) 
Sports 0.883(+/- 0.698(4/- —-0.756(+4/- 
0.043) 0.056) 0.039) 
Media 0.893(+/- 0.778(4/- ——-0.826(+/- 
0.047) 0.065) 0.037) 


5. Conclusion 


This article offered a comprehensive empirical anal- 
ysis of the extensible Hyperledger Fabric blockchain 
technology in a decentralized big network with 
changing peer and payload counts. A scalable 
framework for accurate and real-time monitoring of 
HLF systems was presented. The test data demon- 
strated that the proposed approach was feasible. On 
the other hand, it revealed that the framework’s 
throughput, delay, and resilience are dependent on 
system setup, blockchain network architecture, and 
smart contract complexity procedures. According 
to the findings, as the volume of transactions and 
array timeout increases, so does the delay. It is 
also observed that the number of blocks generated 
and the volume of transactions for each block had 
a greater effect on performance, or the number of 
operations performed per unit time. Due to the 
number of transactions in a single block, all those 
transactions are to be verified at the same instant, 
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resulting in increased performance as block size 
increases. Furthermore, increasing the array time- 
out adds delay because each block must wait even 
though it has completed all transactions. 

To optimize effectiveness, experiments with huge 
network sizes should take into account the optimal 
values of endorsements each ChainCode to a smaller 
peer group. For IoT applications with numerous 
concurrent processes, it might be suggested that 
higher batch-timeout and block sizes are essential 
for keeping good throughput. In order to attain low 
latency, batch timeout as well as block size must be 
minimal for Iot systems with lots of transactions. 

Future work will take into account updating the 
HLF, assessing the use of legitimate data infor- 
mation, and investigating more test cases, such as 
examining the effects of maintaining many Orderers 
just on system’s efficiency as a whole. We’ll look 
more closely at other configuration options includ- 
ing having numerous Hyperledger Fabric organisa- 
tions and having more endorsement peers. 
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